除了RDB持久化功能之外，Redis还提供了AOF（Append Only File）持久化功能。与RDB持久化通过保存数据库中的键值对来记录数 据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来 记录数据库状态的。

          当对空白数据库执行键值对命令时，RDB持久化是将键值保存到RDB文件中，而AOF持久化保存数据库状态的方法是将命令写入到AOF文件中。被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存 的，因为Redis的命令请求协议是纯文本格式，所以我们可以直接打开 一个AOF文件，观察里面的内容。

         AOF持久化功能的实现可以分为命令追加（append）、文件写入、 文件同步（sync）三个步骤。

         当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之 后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区 的末尾：

　　 Redis的服务器进程就是一个事件循环（loop），这个循环中的文件 事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间 事件则负责执行像serverCron函数这样需要定时运行的函数。 因为服务器在处理文件事件时可能会执行写命令，使得一些内容被 追加到aof_buf缓冲区里面，所以在服务器每次结束一个事件循环之前， 它都会调用flushAppendOnlyFile函数，考虑是否需要将aof_buf缓冲区中 的内容写入和保存到AOF文件里面。

        flushAppendOnlyFile函数的行为由服务器配置的appendfsync选项的 值来决定，各个不同值产生的行为。

         如果用户没有主动为appendfsync选项设置值，那么appendfsync选项 的默认值为everysec，关于appendfsync选项的更多信息，请参考Redis项 目附带的示例配置文件redis.conf。

         为了提高文件的写入效率，在现代操作系统中，当用户调用write 函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂 时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过 了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。 这种做法虽然提高了效率，但也为写入数据带来了安全问题，因 为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会 丢失。 为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制 让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数 据的安全性。

         服务器配置appendfsync选项的值直接决定AOF持久化功能的效率 和安全性。

        因为AOF文件里面包含了重建数据库状态所需的所有写命令，所以 服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还 原服务器关闭之前的数据库状态。

        Redis读取AOF文件并还原数据库状态的详细步骤如下：

        因为AOF持久化是通过保存被执行的写命令来记录数据库状态的， 所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件 的体积也会越来越大，如果不加以控制的话，体积过大的AOF文件很可 能对Redis服务器、甚至整个宿主计算机造成影响，并且AOF文件的体 积越大，使用AOF文件来进行数据还原所需的时间就越多。

        为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写 （rewrite）功能。通过该功能，Redis服务器可以创建一个新的AOF文件 来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同， 但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体 积通常会比旧AOF文件的体积要小得多。

        虽然Redis将生成新AOF文件替换旧AOF文件的功能命名为“AOF文 件重写”，但实际上，AOF文件重写并不需要对现有的AOF文件进行任 何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库 状态来实现的。

        举个例子执行了6次list的rpush命令，而重写可以读取这个键的值，然后将6次rpush命令变成一次命令，直接rpush这个键的6个值。

        因为aof_rewrite函数生成的新AOF文件只包含还原当前数据库状态 所必须的命令，所以新AOF文件不会浪费任何硬盘空间。

        注意 在实际中，为了避免在执行命令时造成客户端输入缓冲区溢出，重 写程序在处理列表、哈希表、集合、有序集合这四种可能会带有多个元 素的键时，会先检查键所包含的元素数量，如果元素的数量超过了 redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值，那么重写 程序将使用多条命令来记录键的值，而不单单使用一条命令。 在目前版本中，REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的 值为64，这也就是说，如果一个集合键包含了超过64个元素，那么重写 程序会用多条SADD命令来记录这个集合，并且每条命令设置的元素数 量也为64个。另一方面如果一个列表键包含了超过64个项，那么重写程序会用多 条RPUSH命令来保存这个列表，并且每条命令设置的项数量也为64个。重写程序使用类似的方法处理包含多个元素的有序集合键，以及包 含多个键值对的哈希表键。

        AOF重写程序aof_rewrite函数可以很好地完成创建一个 新AOF文件的任务，但是，因为这个函数会进行大量的写入操作，所以 调用这个函数的线程将被长时间阻塞，因为Redis服务器使用单个线程 来处理命令请求，所以如果由服务器直接调用aof_rewrite函数的话，那 么在重写AOF文件期间，服务期将无法处理客户端发来的命令请求。

        很明显，作为一种辅佐性的维护手段，Redis不希望AOF重写造成 服务器无法处理请求，所以Redis决定将AOF重写程序放到子进程里执行，这样做可以同时达到两个目的：

        不过，使用子进程也有一个问题需要解决，因为子进程在进行AOF 重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对 现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写 后的AOF文件所保存的数据库状态不一致。为了解决这种数据不一致问题，Redis服务器设置了一个AOF重写 缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务 器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和 AOF重写缓冲区。

         这也就是说，在子进程执行AOF重写期间，服务器进程需要执行以 下三个工作：

         这样一来可以保证：

         当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父 进程在接到该信号之后，会调用一个信号处理函数，并执行以下工作：

        1）将AOF重写缓冲区中的所有内容写入到新AOF文件中，这时新 AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。 2）对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF 文件，完成新旧两个AOF文件的替换。

        这个信号处理函数执行完毕之后，父进程就可以继续像往常一样接 受命令请求了。 在整个AOF后台重写过程中，只有信号处理函数执行时会对服务器 进程（父进程）造成阻塞，在其他时候，AOF后台重写都不会阻塞父进程这将AOF重写对服务器性能造成的影响降到了最低。

        举个例子：

 以上就是AOF后台重写，也即是BGREWRITEAOF命令的实现原理。

介绍：

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来（不包含读），只许追加文件但不可以改写文件。redis启动时会读取该文件重新构建数据，redis重启就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

配置：

在redis.conf文件中appendonly 开启，appendonlyname 日志文件名称 ，生成路径和RDB路径相同。

当aof文件发送异常时，可使用usr/local/bin/redis-check-aof--fix aof文件名称 进行恢复 ，备份被写坏的文件，容器redis重新加载。

重写：

AOF采用文件追加方式，文件会越来越大，为了解决这个问题新增了重写机制，当AOF文件大小超过配置文件中设置的阈值时，就会启动。只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理：

AOF文件持续增长过大时，会fork一条新子进程来将文件重写（也就是先写临时文件最后在rename），redis4.0版本后的重写，就是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：配置文件中开启

no-appendfsync-on-rewrite：yes   不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

no-appendfsync-on-rewrite：no   还是会把数据往磁盘里塞，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写：

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

重写虽然节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原理重写后文件的二倍触发）

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

重写流程：

bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

主进程fork出子进程执行重写操作，保证主进程不会阻塞。

子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原aof文件完成以及新aof文件生成期间的新数据修改动作不会丢失。

子进程写完新的aof文件后，向主进程发信号，父进程更新统计信息。主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

AOF持久化流程：

客户端的请求写命令会被append追加到aof缓冲区内。

aof缓冲区根据aof持久化策略【always，everysec，no】将操作sync同步到磁盘的aof文件中。

aof文件大小超过重写策略或手动重写时，会对aof文件rewrite重写，压缩aof文件容量、

redis服务重启时，会重写load加载aof文件中的写操作达到数据恢复的目的。

 优点：

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。缺点

缺点：

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH source destination timeout 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

有三个选项：

每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。

每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。

从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

总是 fsync 的策略在实际使用中非常慢， 即使在 Redis 2.0 对相关的程序进行了改进之后仍是如此 —— 频繁调用 fsync 注定了这种策略不可能快得起来。

以下是 AOF 重写的执行步骤：

Redis 执行 fork() ，现在同时拥有父进程和子进程。

子进程开始将新 AOF 文件的内容写入到临时文件。

对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。

当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。

搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

为最新的 dump.rdb 文件创建一个备份。

将备份放到一个安全的地方。

执行以下两条命令：

确保命令执行之后，数据库的键的数量没有改变。

确保写命令会被正确地追加到 AOF 文件的末尾。

步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。

步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。

在版本号大于等于 2.4 的 Redis 中， BGSAVE 执行的过程中， 不可以执行 BGREWRITEAOF 。 反过来说， 在 BGREWRITEAOF 执行的过程中， 也不可以执行 BGSAVE 。

这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。

如果 BGSAVE 正在执行， 并且用户显示地调用 BGREWRITEAOF 命令， 那么服务器将向用户回复一个 OK 状态， 并告知用户， BGREWRITEAOF 已经被预定执行： 一旦 BGSAVE 执行完毕，BGREWRITEAOF 就会正式开始。

当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。